Day 29: AI 工具鏈選型指南：ChatGPT vs. Codex vs. Claude vs. Local LLMs 比較

18th鐵人賽

蔡

2026-09-20 15:50:08

122 瀏覽

分享至

Day 29: AI 工具鏈選型指南：ChatGPT vs. Codex vs. Claude vs. Local LLMs 比較 (ChatGPT vs Codex vs Claude vs Local LLMs)

本日核心價值 (Core Focus): 用同一組維度比較 ChatGPT、Codex、Claude 與 Local LLM，選的是工作流位置（規劃、repo agent、隱私、成本、工具、離線），不是品牌勝負；最後用決策樹對應到本系列實際會用到的場景。

概念說明與實戰情境 (Overview)
系列走到第 29 天，工具已經夠用，缺的是「哪一段流程該用哪一種執行環境」。把所有任務丟進同一個聊天視窗，會在結構化 API、長時間改碼、敏感資料與離線環境上同時妥協。把所有任務丟進 Local LLM，則常在工具呼叫與測試迴圈上不夠穩。選型原則：ChatGPT 擅長 API、Function Calling 與 Structured Output；Codex 擅長在 Sandbox 裡改碼並跑測試；Claude 作為另一個可替換的 coding agent；Local LLM 放在資料不能出門的路徑，並接受較小的 Context 與較弱的工具生態。以下比較刻意寫能力邊界，不寫廠商攻擊。

關鍵操作與範例 (Implementation & Example)

比較表使用「適配程度」而不是分數。實際產品名稱與額度會變，團隊應把模型名當成可替換設定，把能力槽位當成穩定架構。

維度	ChatGPT（API / Chat）	Codex（CLI / IDE agent）	Claude（coding agent / API）	Local LLMs
聊天與規劃	強：需求拆解、方案比較、規格草稿	中：以任務執行為主，規劃可做但不是長討論場	強：長文規劃、程式推理	中到弱：視模型規模，長規劃較不穩
Repo agents	中：需自建 tool loop	強：讀寫工作區、指令、測試迴圈	強：同樣可當 repo agent	弱到中：要自架 runner 與工具
隱私	資料出站至雲端；企業需看 retention 與地區條款	程式與指令在 agent 環境執行；仍屬雲端模型	雲端模型；企業條款各自評估	強：權重與推論可留在內網
成本	Token 計價，適合短輪次 API	以 agent 時長／訂閱／token 組合計，長迴圈要設上限	Token／訂閱；長 Context 成本需監控	硬體與電費為主，邊際 token 低、維運高
Tool use	強：Function Calling、Structured Output	強：shell、測試、檔案、MCP	強：tool use / computer use 視產品而定	中：要自接 schema 與執行層
離線	否	否（模型在雲端）	否	可：完全離線或 VPC only

四個槽位的建議用法（可並存，不要互斥）：

ChatGPT → API 層。 Day 03、06、07、09、18 這條線：JSON Schema、Function Calling、對內系統查詢。需要穩定契約、可重試、可計費。規劃會議、把錯誤 log 收成假設清單（Day 26）也適合先走聊天。
Codex → 改碼與驗證層。 Day 05、11、12、16、17：在 workspace-write Sandbox 跑測試、自我修復、CI 裡做檢視。AGENTS.md 提供「如何跑測試」。不適合拿它當正式環境的 SQL 執行者。
Claude → 可替換的 coding agent。 當團隊已有 Claude Code 或 API 工作流時，把它放在與 Codex 相同的槽位：改碼、解釋 diff、長檔案重構。輸出同樣要進測試與 Review，不因為換模型就減少閘門（Day 28）。
Local LLM → 敏感資料層。 合約、客戶個資、尚未公開的原始碼掃描，優先落地推論。接受較短 Context，因此更要遵守 Day 02：只送檢索後的片段（Day 23 RAG）而不是整庫。工具呼叫自己做允許清單。

決策樹用任務類型走，不使用「哪個比較聰明」當第一個問題：

資料能否離開公司網路？
- 否：走 Local LLM，只送 RAG 片段，禁止整庫上傳。若仍要改碼，模型只產 patch，測試與 CI 仍在本機 runner 跑。
- 是：問下一個問題。
這次主要產出是什麼？
- 穩定 JSON、呼叫內部 API、聊天機器人： ChatGPT API（Structured Output + Function Calling）。
- 在 repo 裡改檔、跑測試、修到綠燈： Codex，或同等的 Claude coding agent；共用同一套 AGENTS.md 與 CI。
- 長規格、設計權衡、多方案比較： ChatGPT 或 Claude 聊天；結論再交 agent 實作。
- 離線展示、無網、空氣間隙： Local LLM，並把功能縮小到可離線驗證的範圍。

同一產品裡常見的組合，而不是「全公司只准一個模型」：

流程	建議組合	原因
設計 → 實作 → 測試	ChatGPT／Claude 規劃，Codex 實作	規劃需要來回討論；實作需要 Sandbox
ERP／內部查詢機器人	ChatGPT API + 後端工具	契約與權限在應用層，不在聊天視窗
含個資的摘要	Local LLM 或企業私有端點	先滿足資料邊界，再談文筆
CI 檢視	Codex／同等 agent 在隔離 runner	權限與秘密注入可控
成本敏感批次	小模型或 Local；旗艦只做難例	Day 22 的 model selection

Local LLM 的務實預期要寫進選型文件，避免上線後才失望：Context 視窗較小、工具呼叫較不穩、結構化輸出要靠文法約束或重試、多語言程式碼理解隨模型而變。它贏在資料邊界與離線，不贏在「免費取代旗艦 agent」。硬體、模型授權、更新節奏與資安修補都是成本。

把選型寫成 AGENTS.md 或內部 runbook 的一小段即可，避免每次爭論品牌：

## Tooling slots
- Planning & JSON APIs: ChatGPT API（模型名見 `.env.example`）
- Repo edit + tests: Codex CLI, sandbox workspace-write
- Alternate coding agent: Claude（同一測試指令）
- Sensitive corpora: local LLM behind RAG; no raw dumps
- Production SQL/shell: never executed by any model runtime

注意事項與常見失敗 (Pitfalls)

用排行榜代替槽位： 基準測試贏不代表 Function Calling 穩、也不代表 Sandbox 測試迴圈完整。修法：用本系列的任務（結構化輸出、跑 xUnit、解釋 slow query）各做一組金樣例再選。
Local LLM 卻把整份客戶資料庫 schema + 列資料貼進 Prompt： 隱私優勢會被自己抵消。修法：檢索最小片段、遮罩個資、稽核 log。
兩個 coding agent 同時改同一分支且沒有測試閘門： 衝突與「誰覆寫誰」會蓋過模型差異。修法：一個任務一個 agent；CI 是唯一綠燈。
把 ChatGPT 聊天視窗當正式 API： 手動複製輸出無法版本化。修法：正式路徑走 API、schema、eval（Day 03、28）。
忽略離線與出口管制需求直到交付前一週： 修法：決策樹第一個問題永遠是資料能否出網。

本日總結 (Takeaways)

選槽位：規劃／API、repo agent、隱私推論、離線；不要選信仰。
ChatGPT 適合 Structured Output 與 Function Calling；Codex 適合 Sandbox 改碼測試；Claude 可替換 coding agent；Local LLM 守資料邊界。
決策樹先問資料能否出網，再問產出是 JSON、patch 還是長規劃。
成本與隱私是約束，不是事後附加條件。
任何模型產生的程式碼都走同一套測試與 Review，選型不降低 Day 28 的閘門。

明日預告 (Next)
明天完賽總結：當 AI 工作流成為常態，開發者的核心競爭力在哪裡？